<!DOCTYPE html>
            
<HTML>
<HEAD>
<meta name="booktitle" content="Developing Applications With Objective Caml" >
 <meta charset="ISO-8859-1"><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
<META name="GENERATOR" content="hevea 1.05-7 of 2000-02-24">
<META NAME="Author" CONTENT="Christian.Queinnec@lip6.fr">
<LINK rel=stylesheet type="text/css" href="videoc-ocda.css">
<script language="JavaScript" src="videoc.js"><!--
//--></script>
<TITLE>
 To Learn More
</TITLE>
</HEAD>
<BODY class="regularBody">
<A HREF="book-ora157.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="book-ora159.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2> To Learn More</H2>The modular model suffers from weak code reuse and difficulties for
incremental development. The article "Modular Programming with
overloading and delayed linking" ([<A HREF="book-ora214.html#JFLA96AC"><CITE>AC96</CITE></A>]) describes a simple
extension of the module language, allowing the extension of a module
as well as overloading. The choice of code for an overloaded function
derives from the techniques used for generic functions in CLOS. The
correction of the type system to accommodate these extended
modules has not been established.<BR>
<BR>
The issues of mixing the models are well discussed in the article
"Modular Object-Oriented Programming with Units and
Mixing"([<A HREF="book-ora214.html#icfp98"><CITE>FF98</CITE></A>]), in terms of the ease with which code can be
reused. The problem of extensibility of components is described in
detail.<BR>
<BR>
This article is available in HTML at the following address:


<H3> Link </H3> <HR>

<A HREF="http://www.cs.rice.edu/CS/PLT/Publications/icfp98-ff/paper.shtml">http://www.cs.rice.edu/CS/PLT/Publications/icfp98-ff/paper.shtml</A>


<HR>

<BR>
<BR>
We can see in these concepts that there is still some dynamic
typing involved in type constraints and/or the resolution of type
conflicts. It is probably not unreasonable to relax static typing to
obtain languages that are "primarily" statically typed in the pursuit
of increasing the reusability of the code by facilitating its
incremental development.<BR>
<BR>

<BR>
<BR>

<BR>
<BR>
<BR>
<BR>
<HR>
<A HREF="book-ora157.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="book-ora159.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
